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[Text]  0.  SUMMARY 


The  Commission  of  the  European  Communities  has  produced  a  set  of  guidelines  for 
the  way  informatic  services  should  be  used  within  its  own  administration,  and 
for  the  way  informatics  resources  should  be  deployed.  It  is  expected  that  they 
will  lay  the  foundations  of  a  well-coordinated  plan  for  procurement  and 
implementation  of  informatics  across  European  Institutions. 

The  plan,  as  expressed  by  these  guidelines,  has,  as  its  basic  aim,  to  allow  the 
European  Institutions  to  : 

Be  free  to  choose  the  best  way  of  adopting  and  integrating  new  technology 
independently  of  the  policy  of  individual  manufacturers. 

The  stated  objectives  to  achieve  this  aim  are  : 

*  To  modernise  the  administration  of  the  European  Institutions  and  organise 
the  flow  of  information  between  them  and  the  Member  States  Administrations 
by  the  INSIS  programme  (Interinstitutional  System  for  Integrated  Services). 

*  To  implement  a  multi-vendor  procurement  policy,  showing  that  it  is 
economically  justified  in  a  standardised  environment. 

*  To  promote  cooperation  between  manufacturers  in  promulgating  standards  and 
adhering  to  them. 

*  To  strengthen  interinstitutional  cooperation  in  informatics  allowing  the 
sharing  of  benefits  resulting  from  the  combination  of  the  purchasing  power 
of  separate  Institutions. 

*  To  set  an  example  to  public  and  private  bodies  in  Europe  in  procurement 
policy  for  informatics  products. 

There  are  two  main,  closely  related,  fronts  through  which  the  guidelines 
propose  to  implement  these  aims  : 

A  coherent  policy  in  implementing  standards  ; 

A  rational  deployment  of  informatics  resources,  reflecting  more  closely  the 
way  user  communities  are  organised. 
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Standards  are  essential  for  intercommunication  between  institutions  and 
eventually  interworking.  They  are  also  essential  for  interconnection, 
intercommunication  and  interworking  within  a  single  institution.  Last,  but  not 
least,  they  are  essentiel  for  the  independence  from  individual  manufacturers, 
the  protection  of  investment* against  obsolescence  and  for  the  free  competition 
within  the  informatics  industry. 

The  guidelines  adopt  fully,  and  on  a  mandatory  basis,  the  implementation  of  the 
principle  of  Open  Systems  Interconnection  (OSI)  for  all  matters  that  involve 
communication  between  different  equipment  and  institutions.  They  go  further 
than  the  OSI  principle,  however,  by  proposing  practical  ways  of  cooperating  in 
the  implementation  of  application  s^tems  with  view  to  interworking  on  an 
user-to-user  basis,  as  opposed  to  simply  machine-to-machine . 

The  proposed  measures  include  the  urgent  adoption  of  a  standards  intercept 
strategy,  in  concert  with  the  manufacturers  who  will  implement  them  on  their 
products,  as  well  as  the  adoption  of  a  limited  range  of  software  products  to 
avoid  the  proliferation  of  incompatible  systems.  A  good  example  of  the  latter 
is  a  decision  not  to  introduce  new  proprietory  operating  systems,  and  the 
choice  of  transportable  ones,  such  as  UNIX  and  MS-DOS.  These  enhance  the  common 
development  and  interchange  of  applications,  and  make  possible  the  introduction 
of  an  unified  user  environment. 

The  deployment  of  informatics  resources  proposed  in  the  guidelines  is  based  on 
a  distributed  architecture  which  reflects  closely  the  way  user  communities  are 
organised.  The  open  systems  principles  resulting  from  the  adoption  /o,^ /suitable 
standards  provide  the  flexibility  needed  to  implement  the  '^(pij^posed 
architecture. 

Essentially,  this  is  a  two  level  architecture  which  distinguishes,  within  an 
Institution,  between  Local  Support  Units  (LSUs)  dedicated  to  a  local  user 
community  with  a  close  working  relationship  and  Common  Support  Units  (CSU) 
dedicated  to  the  organization  as  a  whole. 

LSUs  are  intended  to  cover  flexibly  the  different  user  requirements  of 
different  user  communities.  CSUs  are  used  for  services  that  cannot  be  provided 
economically  within  a  small  user  community,  cannot  be  practically  distributed 
(e.g.  common  data  bases),  or  are  centralised  by  definition,  such  as  common 
accounting,  communication  between  organizations,  etc. 

The  guidelines  recognise  the  fact  that  the  capabilities  offered  by  information 
technology  finally  reach  the  users  in  the  form  of  different  services  such  as 
electronic  mail,  personal  computing,  access  to  data  bases,  etc.  For  this 
reason,  a  substantial  part  of  the  guidelines  is  dedicated  to  these  services  and 
is  of  a  dynamic  nature.  The  guidelines  for  the  implementation  of  services  will 
be  constantly  under  review  and  new  guidance  will  be  added  as  experience  is 
gained  and  as  new  requirements  materialise. 

The  guidelines  also  recognise  the  fact  that  the  transition  from  a  manufacturer 
oriented  architecture  to  an  open  one  allowing  full  interworking  cannot  be 
achieved  overnight.  The  guidelines  foresee  an  evolutionary  plan  which  will 
gradually  attain  the  intended  goal.  This  plan  contains  valuable  information  for 
the  industry  on  the  difficulties  a  customer  meets  when  implementing  a 
multi-vendor  standards  policy. 
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It  is  believed  that  the  plan  inherent  in  the  guidelines  is  both  urgent  and 
timely.  Although  information  technology  is  not  new  and  expands  at  an  increasing 
pace,  its  usage  in  a  wide  scale  is  still  in  its  formative  stages.  A  plan,  and 
the  cooperation  of  all  manufacturers  of  the  expanding  technology  in  it,  is 
essential  if  the  resulting  systems  are  to  allow  users  in  different 
organisations  to  interwork. 
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1,  INTRODUCTION 


The  unprecedented  growth  in  information  and  communication  technology  of  the 
past  years  presents  both  challenge  and  opportunity  to  user  organisations. 

The  opportunity  is  that  technology  can  be  applied  to  enhance  the 
effectiveness  and  efficiency  of  organisations  to  a  higher  degree  than  was 
possible  before. 

The  challenge  is  caused  by  the  proliferation  of  products  which  makes 
standardisation  a  pre-requisite  for  integration. 

It  is  in  the  interest  of  all,  and  especially  of  large  organisations,  to  : 

Remain  free  to  choose  the  best  way  to  adopt  and  integrate  new  technology 
independently  of  the  policy  of  individual  manufacturers. 

In  addition,  the  European  Institutions  must  cope  with  the  complexity  caused  by 
different  languages  and  partners  in  remote  geographical  locations.  This  turns 
the  interest  into  a  necessity,  and  dictates  conditions  for  a  high  degree  of 
flexibility  in  implementing  these  technologies. 

The  degree  of  interaction  between  the  European  Institutions  makes  essential  the 
adoption  of  a  master  plan  for  implementing  the  growing  technologies.  This 
should  encompass  communications  and  areas  of  common  interest  between  European 
Institutions  and  the  Administrations  of  the  Member  States  of  the  European 
Community. 

The  proposed  master  plan  (the  Informatics  Architecture  of  the  European 
Institutions)  has  as  its  main  elements  : 

*  A  distributed  data  processing  architecture. 

*  A  multi-vendor  procurement  policy. 

*  Common  standards  for  system  interworking. 

*  Maximum  transportability  of  software. 

This  architecture  ought  to  reflect  more  than  the  solution  to  the  needs  of  the 
European  Institutions.  The  European  Institutions  have  to  play  a  leading  role  to 
encourage  harmonisation  in  informatics,  which  should  be  to  the  benefit  of 
European  industry  at  large. 


The  following  objectives  are,  therefore,  adopted  to  achieve  the  goals  set  out 
earlier  : 

a  To  modernise  the  administration  of  the  European  Institutions  and  organise 
the  information  flow  between  them  and  the  Member  State  Administrations  by 
the  INS  I S  programme  ( Interinstitutional  System  for  Integrated  Services), 
and  CADOIA  (Cooperation  in  Automation  of  Date  and  Documentation  for 
Import/Export  and  Agriculture). 

b  To  demonstrate  that  a  multi-vendor  procurement  policy  is  economically 

justified  in  a  standardised  environment  because  it  reduces  the  cost  of 
dependence  on  a  single  supplier  while  avoiding  the  cost  of  hardware 
redundancy. 

c  To  obtain  an  undertaking  from  manufacturers  to  cooperate  in  promulgating 
standards  and  to  comply  with  them  in  the  products  they  offer  to  all  their 
customers . 

d  To  strengthen  interinstitutional  cooperation  in  informatics.  This  will 

allow  the  sharing  of  benefits  between  Community  Institutions  who  have  their 
own  purchasing  power. 

e  To  set  an  example  to  public  and  private  bodies  in  Europe  in  procurement 
policy  for  informatics’  products. 

The  tasks  set  out  are  not  easy.  Most  architectures  have  been  designed  by  the 

computer  manufacturers  to  fit  with  their  present  and  future  product  ranges. 

Such  architectures  are,  generally,  mutually  incompatible  even  if  OSI  standards 
are  applied.  A  multi-vendor  architecture  can  only  be  developed  by  the  customer, 
but  no  single  customer  has  the  power  to  impose  a  given  architectural  design  on 

industry.  A  multi-vendor  architecture  must,  consequently,  result  from  the 

iterative  process  of  demand  and  supply. 

This  is  the  spirit  in  which  these  architectural  guidelines  have  been  prepared. 
They  reflect  neither  too  specific  customer  needs,  nor  particular  design 
concepts  ;  moreover,  they  take  into  account  the  availability  of  products  on  the 
market.  This  is  an  additional  reason  why  the  guidelines  themselves  are  under 
constant  review  and  correction,  and  why  some  important  subjects  are  not 
included  when  the  standardisation  process  does  not  point  to  general  and  common 
sense  solutions.  In  the  next  edition  of  the  guidelines  a  more  advanced  analysis 
of  some  of  these  subjects  will  be  covered,  such  as: 

*  Introduction  of  ISDN  and  final  selection  of  LAN  standards  ; 

*  Network  management  and  addressing  scheme 

*  Encryption  ; 

*  Integration  of  servers  ; 

*  User  interface  standardisation  ; 

*  Document  management. 
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The  Commission  of  the  European  Communities  would  be  grateful  to  receive 
information  and  suggestions  for  the  next  edition  of  these  guidelines  at  the 
following  address,  where  also  extra  copies  of  this  document  can  be  ordered. 


COMMISSION  OF  THE  EUROPEAN  COMMUNITIES 
Directorate  of  Informatics 
Jean  Monnet  Building  -  Room  C2-84 
L-2920  LUXEMBOURG 
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2.  ARCHITECTURE 


2.1  Structuring 

The  aim  of  the  architecture  is  to  fulfil  the  objectives  stated  in  the 
introduction  and  allow  the  integration  of  data,  text,  graphics,  image,  voice, 
etc.:  it  is  an  open  architecture. 

To  the  end  user,  the  architecture  appears  as  services  delivered  via  a  single 
workstation.  Some  important  services,  to  which  attention  will  need  to  be  paid 
in  the  1986-1991  period,  are  :  user  agent  services,  information  production  and 
administration,  information  dissemination  service,  electronic  mail,  and 
application  services. 

User  populations  of  autonomous  organisations,  such  as  private  companies, 
government  administrations  and  European  Institutions,  have  independent 
informatics  management  structures.  Following  the  CCITT  (1)  terminology,  they 
will  be  called  Private  Domains.  Private  domains  will  communicate  via  Public 
Communication  Networks  (PC.N)  and  use  services  delivered  by  Public  Domains, 
which  are  managed  by  public  telecommunication  administrations  (PTTs). 


(1)  CCITT  =  International  Telegraph  and  Telephone  Consultative  Committee 
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The  distinction  between  public  and  private  domains  implies  a  distinction 
between  an  inter-  and  intra-domain  architecture.  The  first  has  to  be  determined 
by  common  agreement  between  all  domains  concerned.  The  management  of  each 
domain  is  autonomous  in  determining  its  intra-domain  archit ecture .  The 
definition  of  the  intra-domain  architecture,  however,  is  significant  if 
end-user  interworking  across  domains  is  to  be  achieved. 

The  intra-domain  architecture  of  the  CEC  is  based  on  distributed  processing. 
Services  are  provided  by  means  of  hardware,  software,  networks,  and  support 
(the  infrastructure). 

The  user  accesses  the  architecture  through  a  workstation.  A  workstation  may  be 
a  telephone  set,  visual  display,  keyboard,  printer,  document  entry  station, 
etc.  Ideally,  the  user  should  need  just  a  single  multi-function  workstation  to 
access  all  available  services.  How  services  are  obtained  beyond  the  workstation 
should  be  transparent. 

Thu  workstation  communicates  with  hosts  distributed  in  the  network.  A  host  is  a 
computer  with  its  operating  system  and  its  communication  interfaces.  It 
provides  the  host  environment  for  a  set  of  servers.  A  server  is  a  software 
package  and  the  resources  it  draws  from  its  host.  In  order  to  deliver  a  service 
to  the  user,  (such  as  access  to  data  bases,  electronic  mail,  information 
production,  document  management  and  application  services),  it  is  necessary  to 
set  up  a  flow  of  communication  between  cooperating  servers  which  together 
produce  the  service  (*) 


Host  1 


Host  3 


Diaq. 


(*)  The  term  "service*  in  this  document  means  "service  to  the  user",  and  does 
not  refer  to  the  service  that  exists  between  the  layers  of  the  OSI  model. 
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In  order  to  cope  with  all  possible  combinations  of  hosts  and  servers,  which  may 
occur  in  the  course  of  time,  it  must  be  technically  possible  for  any  server  to 
communicate  with  any  other  server.  This  implies  the  principle  of  Open  System 
Interconnection  (OSI)  and  the  implementation  of  the  related  standards  (see  § 
3.2) 

However,  OSI  is  only  a  means  to  the  end  of  constructing  a  good  architecture. 
The  architecture  itself  is  the  structure  of  the  solution  to  the  needs  of  the 
users  and  must  define  : 

how  services  are  set  up  by  cooperating  servers 

how  servers  are  mapped  onto  hosts 

how  hosts  are  distributed  into  the  network. 

To  answer  these  questions,  the  distinction  between  “host1*  and  "server"  made 
above  is  of  material  importance. 

The  architecture  consists  of  rules  for  structuring  ;  not  rigid  pre-defined 
structures.  The  rules  themselves  will  change  in  the  course  of  both  technical 
evolution,  and  eventual  changes  in  the  users'  pattern  of  behaviour.  The  rules 
are  dictated  by  the  technical,  functional,  and  economical  relationships  between 
technology  on  the  one  hand,  and  user  activity  on  the  other.  The  resulting 
architecture  must,  at  any  one  time  : 

Fit  the  organisational  structure  of  user  populations,  resulting  in 
unambiguous  relationships  regarding  responsibility  and  management  of 
the  use  of  informatics. 

Fit  the  operational  structure  of  user  populations,  resulting  in  an 
easier  flow  of  information. 

Effect  the  match  between  the  users*  needs  and  the  resources  to  fulfil 
them  in  an  economical  manner. 

2.2  Distribution  of  Hosts 

The  basic  organisational  entity  is  the  Local  User  Community.  It  must  have  a 
close  working  relationship  and  be  characterised  by  intensive  interworking  and  a 
common  requirement  for  specific  sets  of  services.  This  should  justify  the  cost 
of  providing  local  support  and'management . 

From  both  an  organisational  and  operational  point  of  view,  there  is  a 
requirement  that  this  local  support  and  management  should  cover  : 

The  administration  of  equipment  (including  hardware,  software,  data 
and  local  communications)  ; 

The  control  of  access  to  these  resources  from  both  the  economical  and 
security  points  of  view,  including  identification,  authentication  and 
addressing  of  users. 
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A  local  user  community  will  generally  coincide  with  an  organisational  unit  such 
as  a  department  within  a  single  site.  "Site"  is  not  necessarily  the  same  as 
"building".  There  may  be  more  than  one  site  within  a  building,  or  there  may 
exist  links  between  buildings  to  enable  treatment  as  an  unit. 

The  hardware,  software  and  support  which  is  dedicated  to  a  local  user  community 
is  called  a  Local  Support  Unit  ILSUI  and  it  is  put  under  the  operational 
supervision  of  a  Local  Systems  Administrator  (LSA). 

A  LSU  should  serve  as  large  a  user  community  as  possible.  If,  however,  a  user 
community  is  divided  geographically  in  a  manner  that  cannot  be  supported 
economically  by  a  single  LSU,  it  should  be  served  by  different  LSUs.  Similarly, 
if  a  large  user  community  consists  of  groups  carrying  out  activities  with 
little  or  no  interaction,  it  should  be  served  by  different  LSUs. 

As  an  LSU  is  thus  an  autonomous  unit,  whose  physical  separation  enhances  its 
security . 

An  LSU  is  composed  of  local  hosts,  personal  hosts  and  workstations  with  the 
necessary  servers.  A  personal  host  is  dedicated  to  a  single  user  at  a  time  and 
therefore  is,  in  principle,  built  into  a  self-contained  workstation,  such  as  a 
personal  computer  (PC). 

The  resources  within  an  LSU  are  interconnected  through  a  Local  Communications 
Network  (LCN).  As  the  LSU  itself,  an  LCN  is  a  conceptual/organisational  link 
between  resources  and  does  not  imply  a  specific  technology.  It  can  be 
implemented  through  various  technologies  such  as  asynchronous  communications,  a 
packet  switching  network,  or  a  Local  Area  Network  (LAN).  The  term  LAN  whenever 
encountered  in  this  document  does  not  refer  to  the  LCN,  but  to  a  specific 
technology  through  which  it  is  implemented. 

Hosts  which,  for  whatever  reason,  are  not  part  of  an  LSU,  but  deliver  services 
to  families  of  LSUs,  to  the  entire  private  domain  in  which  they  operate,  or  to 
other  private  domains,  are  called  common  hosts.  They  constitute  Common  Support 
Units  ( CSU )  under  the  operational  supervision  of  Common  Systems  Administrators 
(CSA). 

The  geographical  location  of  CSUs  is  generally  remote  from  the  LSUs.  They  are 
concentrated  in  Computer  Centres  or  in  Telecommunication  Centres. 

LSUs  and  CSUs  are  interconnected  by  a  Domain  Communication  Network  (DCN)  while 
interdomain  communication  uses  the  Public  Communication  Networks  (PCN). 

The  relationship  between  the  support  units  of  a  domain,  and  the  inter-domain 
relationships  are  shown  in  the  next  diagram  : 
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The  two  level  architecture  of  IStJs  and  CSUs  is  intended  for  large  and 
geographically  spread  organisations.  Small  organisations  located  in  one 
building  are  suggested  , to  follow  an  architecture  similar  to  a  that  of  single 
LSD .  A  gateway  to j  the  public  networks  could,  then  contain  a  mini 
telecommunication  centre.  ^  "v- 

Si;t 

Other  deviations  from  the  general  model  may  occur  when  members  of  a  local  user 
community  are  not  in  the  same  office  area  but  at  a  larger  distance-  If  this  is 
an  exception,  a  pragmatic  ad-hoc  solution  must  be  found  without  changing  the 
architecture  guidelines.  There  are  cases,  however,  where  user  communities  are 
spread  ovei  different  countries  (e.g.  international  committees),  or  even 
composed  of  mobile  members  (e.g.  members  of  the  European  Parliament). 

Two  solutions  are  then  recommended  : 

If  there  can  exist,  somewhere,  administrative  and/or  secretarial  support 
for  the  community,  this  can  be  organised  as  an  LSU  providing  a  service 
access  point.  The  distant  workstations,  preferably  personal  computers,  are 
then  connected  by  the  inter-  and  intra-domain  communication  networks  to  the 
LSU  from  where  all  the  services  for  the  local  community  can  be  accessed  ; 

If  such  a  service  entry  point  cannot  be  provided,  each  member  is  then 
equipped  with  a  “single  workstation  LSU",  again  based  on  a  personal 
computer,  but  even,  in  some  cases,  simply  with  a  terminal  linked  to  the 
Videotex  services  provided  by  the  national  PTTs  ;  the  latter  provides 
almost  a  "unidirectional"  LSU.  In  this  solution,  isolated  autonomous  users 
are  considered  as  single  member  communities. 
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2.3  Distribution  of  Servers 


Servers  can  be  classified  in  different  categories  : 

a  personal  server  can  be  allocated  to  a  single  user 

a  local  server  cannot  be  allocated  to  a  single  user  because  its  services 
are,  by  definition,  to  be  shared  by  the  members  of  a  local  user  community 
(e.g.  departmental  data) 

a  common  server  cannot  be  allocated  to  a  local  user  community  because  its 
services  are,  by  definition,  to  be  shared  by  several  local  user 
communities,  the  whole  domain,  and  possibly  user  communities  outside  the 
domain. 

an  external  server,  by  definition,  has  to  be  accessed  through  inter-domain 
communication . 

In  general,  the  distribution  of  servers  follows  the  pattern  of  distribution  of 
data  . 

It  seems  logical  to  locate  personal,  local  and  common  servers  on  personal, 
local  and  common  hosts  respectively.  For  diminishing  technical  and  economical 
reasons,  servers  are  often  installed  further  upstream  from  the  user  ;  in  the 
past,  all  servers  were  located  on  a  common  central  computer. 

It  is  therefore  possible  that  text  and  graphical  processing  are  still  provided 
by  local  and  even  common  hosts,  and  that  local  applications,  including  local 
data  bases,  are  run  on  common  hosts.  This  would  be  the  exception  rather  than 
the  rule.  Heavy  batch  processing  and  number  crunching  will  continue  on  large 
mainframes  for  economical  reasons. 

It  is  technically  feasible  to  locate  servers  downstream  from  their  normal 
position  and  place  common  servers  on  local  hosts.  This  would  be  undesirable, 
for  purely  organisational  reasons  :  to  migrate  from  a  centralised  way  of  using 
informatics  to  one  in  which  any  user  community  can  provide  services  to  any 
other  is  associated  with  problems  of  security,  responsibility  and  resource 
management.  Such  an  approach  is,  therefore,  in  contradiction  with  the 
organisational  principles  of  the  architecture,  stating  that  only  CSUs  have  the 
mission  of  a  domain  wide  coverage  of  services. 

Although  it  should  be  technically  possible  for  any  server  to  communicate  with 
any  other  server  (see  dotted  lines  on  next  diagram),  the  architecture  must  also 
foresee  features  allowing  or  obliging  the  user  to  call  upon  a  local  server 
before  accessing  a  common  server,  or  a  common  server  before  accessing  an 
external  one.  This  will  assure  compatibility  bridging,  added  value  operations, 
security  and  better  administration  and  control.  Local  and  common  hosts  and 
servers  must,  therefore,  provide  adequate  pass-through  facilities. 
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Diag.04 

In  summary,  servers  are  the  resources  in  operational  form.  They  have  to  respond 
directly  to  user  requirements  ;  their  operation  must  follow  the  organisational 
structure  of  the  users. 

The  mapping  of  personal,  local  and  central  servers  on  personal,  local  and 
central  hosts  should  follow  the  dictates  of  economics.  If  it  were  ever 
necessary  to  map  a  personal  server  on  a  central  host,  this  would  be  for 
economical,  and  not  technical  or  organisational  considerations. 

Such  mapping  as  there  may  be  should,  as  much  as  possible,  be  transparent  and 
convenient  to  the  end  user.  Hence,  an  emphasis  on  'pass-through  facilities 
enable  different  hosts,  and  through  them  servers,  to  be  accessed  from  a  single 
workstation. 


2,4  Constraints 

The  planned  architecture  cannot  be  achieved  overnight  because  : 

*  Many  of  the  standards  necessary  for  fully  open  systems  do  not  exist  yet, 
especially  in  the  higher  levels  of  the  OSI  model. 

*  The  state  of  the  art  of  integration  is  not  mature  enough  for  the 

implementation  of  the  architecture.  Industry  progresses  slowly  and  in 
different  directions  in  the  development  of  standard  products.  The  PTTs  have 
not  progressed  enough  in  the  consistent  implementation  of  their  own 
standards  at  the  European  level. 

*  The  shift  from  central  to  local  processing  and  from  domain  to  local 

communications  should  not  take  place  at  a  faster  rate  than  can  be 
economically  justified.  An  economical  balance  must  be  struck  between  the 
rate  of  decrease  in  local  hardware  costs,  the  cost  of  new  software,  and  the 
need  to  avoid  chronic  congestion  of  the  CSUs  and  the  OCN. 
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*  The  economical  life  cycle  of  existing  equipment  must  be  taken  into  account 
for  its  economical  replacement. 

*  The  training  needed  to  implement  the  plan  is  considerable.  It  can  only  be 

carried  out  over  some  time  ;  especially  as  not  all  users  have  the  same 

degree  of  motivation. 

A  gradual  attainment  of  the  goal  is  necessary.  The  speed  of  evolution  will 

depend  on  the  factors  mentioned  above,  as  well  as  on  technological  development. 


2.5  Evolution 


In  the  past,  central  hosts 
networks  of  terminals  and 
communication  methods.  There 
different  "empires”.  This  is 


from  different  manufacturers  generated  separate 
remote  job  entry  points  through  proprietory 
was  little  interconnection  between  equipment  from 
shown  in  the  diagram  below  : 
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The  diagram  that  follows  shows  the  principles  of  implementation  of  the 
organisation  shown  in  section  2.2. 


Diag-06 


This  diagram  shows  an  aim  to  carry  out  communication  between  domains  primarily 
through  the  Integrated  Service  Data  Network  (ISDN).  At  the  local  level,  the 
equipment  of  an  LSU  is  connected  through  the  local  communication  network, 
implemented  as  a  Local  Area  Network  (LAN). 

The  transition  from  the  past  architecture  (fig. 05)  to  the  future  one  (fig. 06) 
must  be  carried  out  in  steps  forming  an  evolution  which  takes  into  account  the 
constraints  explained  in  section  2.4.  The  implementation  of  these  steps  is  the 
following  (with  the  CEC  plan  shown  in  brackets)  : 

Replacement  of  proprietory  terminals  by  multi-protocol  terminals  (84-86) 

Expansion  of  local  computers  supporting  standard  terminal  and  personal 
computer  connections  with  pass-through  to  CSlJ’s  (  83-90) 

Introduction  of  multi-vendor  operating  systems  for  LSUs  (UNIX  and  MS-DOS) 
(84-90) 
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Introduction  of  packet  switching  data  network  for  DCN  and  LCN  communication 
(85),  and  phasing  out  of  binary  synchronous  communication  (85-87) 

Installation  of  multi-vendor  file  and  job  transfer  (1983-1987) 

Installation  of  software  products  (e.g.  DBMS)  covering  as  many 

CSU-mainframes  as  possible  (84-87) 

Selection  of  office  and  professional  software  products  for  selected 
operating  systems  creating  a  common  end-user  environment  (85-87) 

Phasing  out  of  stand-alone  text  processors  to  be  replaced  by  personal 
computers  supporting  equivalent  text  processing  functions  (86-90) 

Implementation  of  electronic  mail  services  (86-90) 

Construction  of  Telecommunication  Centre  (07-88) 

Introduction  of  standard  LAN- technology  for  LCNs  in  order  to  off-load  the 
PSON  and  assure  integration  and  resource  sharing  of  LSI!  equipment  (07-90) 

High  speed  interconnection*of  computer  centre  mainframes  (88) 

Introduction  of  User  Agent  Services  (see  5.1)  and  Information  Dissemination 
Services  (see  5.3)  (87-89) 

Replacement  of  DCN  telephone  and  packet  switching  data  network  by  ISDN 
(1991  and  beyond) 
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3 .  STANDARDS 


3.1  Interworking 

The  ability  of  users  in  different  domains  to  interwork  is  an  important  aim  of 
the  architecture.  Standards  are  essential  for  integration  of  data,  text, 
graphics,  image,  voice,  etc.  in  an  interworking  environment,  and  condition  the 
decisions  on  the  structure  of  the  proposed  architecture. 


There  exist  the  following  problems  : 


*  Complete  and  option  free  sets  of  interrelated  standards  must  be  available 
to  implement  end-to-end  interworking. 

The  development  of  international  standards  has  not  reached  this  state  of 
completeness,  especially  in  the  upper  layers  of  the  OSI  model. 

The  Functional  Standard  Profiles  brought  forward  by  CEN/CENELEC/CEPT  and 
the  industry  are  the  appropriate  solution  to  this  problem.  They  will  be 
adhered  to  completely,  as  well  as  the  European  standards  resulting  from 
them  (EN>. 

*  In  order  to  turn  a  paper  standard  into  a  de-facto  standard,  it  is  necessary 
that  it  should  be  implemented  on  the  market  place  as  dictated  by  market 
forces . 


*  When  a  product  claims  compliance  with  a  standard,  there  must  exist  a  means 
of  testing  this  claim.  The  creation  of  Conformance  Testing  Centres  (CTCs) 
is  an  important  element  in  this  and  will  be  used  for  testing  such 
compliance . 


The  following  elements  of  standardisation  play  an  important  role  in  the 
implementation  of  the  proposed  architecture  : 


Open  Systems  Interconnection  (OSI) 
Transportability  of  Software 
Human  Interworking 
Security  and  Resource  Management 
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3.2  Open  Systems  Interconnection  -  I0SI) 

The  OSI  principle  will  be  applied  throughout.  This  is  a  recommendation  from  the 
International  Standards  Organisation  (ISO),  laying  out  the  guidelines  for  a 
layered  model  of  communication.  It  must  be  interpreted  compatibly  in  the 
creation  of  different  standards. 

The  layers  on  which  international  agreement  has  been  reached,  allow 
equipment  to  intercommunicate  but  not  to  interwork.  The  following  rules  are 
laid  out  in  the  context  of  an  intercept  strategy  : 

*  The  implementation  of  international  standards  becomes  mandatory  as  soon  as 
commercially  available  products  make  it  feasible. 

*  Protocols  corresponding  to  OSI  levels,  for  which  an  international  standard 
is  not  ratified,  will  be  implemented  with  intercept  standards.  There  is  an 
urgent  need  for  a  full  set  of  intercepts  to  be  completed,  especially  for 
the  upper  layers. 


3.3  Transportability  of  Servers  and  Operating  Systems 

To  benefit  from  independence  from  individual  manufacturers,  it  should  be 
possible  to  place  the  same  servers  on  different  hosts.  Thus  : 

*  Conversion  and  disturbance  costs  are  reduced  when  changing  computers, 
especially  as  their  product  life-span  has  become  much  shorter  than  that  of 
software  ; 

*  Application  servers  can  be  shared  ; 

*  Training  and  staff  costs  are  reduced  ; 

Transportable,  manufacturer-independent,  operating  systems  have  been  maturing 
in  recent  years.  These  provide  the  conditions  for  the  development  of  commonly 
supported  software,  by  enlarging  the  size  of  the  market  for  any  one  product. 

Commonly  available  operating  systems  should  be  de-facto  standards  as  long  as  no 
application  interface  standards  exist. 


3.4  Human  Interworking 

Interworking,  as  understood  by  the  user,  involves  a  broader  environment  than 
OSI  and  portability.  Integration  through  "user"  standards  is  needed  in  areas 
such  as  : 

*  Common  command  and  access  procedures 

*  Common  terminology 

*  Common  definition  of  office  procedures 

The  issues  arising  out  of  these  requirements  are  discussed  further  in  chapter  5 

of  this  report. 
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3.5  Security  and  Resource  Management 


More  users  can  access  a  single  host  or  server  through  a  network  than  ever 
before  ;  the  identity  of  these  users  is  not  always  easy  to  establish. 

Economical  use  of  resources,  priority  settlement,  and  control  of  usage  to  avoid 
congestion,  overload,  and  degradation  of  quality  of  service  have  become  major 
issues  of  concern. 

These  are  not  communication  problems,  but  ones  of  security  and  management  of 
resources.  There  are  very  few  standards  in  these  areas  and  their  promulgation 
is  urgent.  They  should  cover  identification  and  authentication  procedures  for 
people  and  equipment,  encryption,  access  control,  accounting,  and 
implementation  of  rules  of  internal  control. 
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4.  IMPLEMENTATION  OF  THE  ARCHITECTURE 


4.1  Implementation  Strategy 

To  implement  the  architecture  in  a  gradual  and  coherent  manner,  a  strategy, 
ensuring  that  standards  are  not  only  created  but  also  encouraged  in  their 
implementation  and  adhered  to  in  the  use  of  informatics,  is  needed.  This  has 
the  following  elements  : 

*  The  process  of  standards  making  and  intercepting  ought  to  be 
accelerated.  This  is  recognised  by  the  CEC,  the  Member  States  and 
industry  alike,  and  the  effort  put  in  the  SOGT-CEPT  and 
SOGITS-CEN/CENELEC  should  be  followed  closely. 

The  priorities  must  be  defined  in  line  with  the  customer 
implementation  problems,  which  are  in  the  first  instance  the  phasing 
out  of  proprietory  protocols  for  remote  interactive  communication, 
file  transfer  and  message  handling,  as  well  as  the  creation  of  stable 
application  interfaces. 

*  The  cooperation  of  vendors  of  different  informatics  products  and 
services  with  each  other  as  well  as  with  the  CEC  ought  to  continue  and 
be  extended  in  new  areas  to  ensure  that  standard  solutions  to  problems 
are  furnished,  and  that  any  adaptations  in  existing  products  are  made 
available  to  the  whole  market. 

The  present  guidelines  provide  valuable  information  for  industry  on 
the  critical  problems  a  customer  meets  when  implementing  a 
multi-vendor  standards  policy. 

*  The  cooperation  of  the  PTTs  must  be  ensured  in  permitting  identical 
implementations  of  standards  in  different  public  domains.  Without 
this,  inter-domain  interworking  will  be  hampered  by  inefficiency  and 
high  costs  of  communication,  even  in  the  most  standardised 
intra-domain  solutions. 

*  Cooperation  between  the  European  Institutions  and  the  Administrations 
of  the  Member  States  should  continue  with  common  projects  such  as 
I  NS  I S  and  CAOOIA,  and  even  enhanced,  to  achieve  the  level  of  agreement 
and  standardisation  necessary  for  inter-domain  communication.  This  is 
important,  given  that  integration  will  not  take  place  on  a  separate 
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network  alongside  the  national  ones,  but  at  the  level  of  the  national 
networks.  It  will  convert  the  intercommunication  to  be  achieved  in 
cooperation  with  the  PTTs  to  interworking  between  domains. 

*  The  European  Institutions  and  the  Administrations  of  the  Member  States 
can  state  their  requirements  through  their  role  as  "clients"  of 
information  technology.  The  establishment  of  a  procurement  policy 
based  on  common  procurement  specifications  has  a  very  positive  role  to 
play,  and  the  role  of  the  Standards  Implementation  Committee  (SIC)  in 
promoting  the  architecture  is  a  key  one,  ensuring  that  compatible 
options  are  selected  and  that  testing  compliance  of  products  is 
feasible. 

*  The  resources,  hardware  and  software,  which,  for  the  components  of  the 
proposed  architecture,  are  obtained  through  calls  for  tender.  These  will 
insist  on  adherence  to  common  procurement  specifications.  A  simplified  and 
well  publicised  tendering  procedure  will  be  adopted,  able  to  be  carried  out 
on  an  almost  permanent  basis.  This  will  allow  : 

Evenly  spread  workload  in  updating  procurement  specifications  ; 
Possibility  of  new  products,  improving  the  architecture,  to  be 
considered  as  soon  as  they  are  available  on  the  market  ; 

Reduction  of  tender  preparation  workload  for  the  suppliers  ; 

Simplified  screening  of  products  and  evenly  spread  workload  in  testing 
them  ; 

High  visibility  of  procurement  policy  and  implementation  of 
standards,  both  for  the  suppliers  and  the  Administrations  of  the 
Member  States  ; 

Advance  information  on  requirements  which  become  mandatory  for  future 
calls  for  tender. 

*  The  end  users  of  informatics  must  be  aware  of  the  strategy  adopted.  To 
encourage  the  adoption  of  this  strategy  in  user  communities,  guidelines  for 
the  use  of  hardware  and  software  have  been  prepared.  These  define  the 
categories  of  products  in  terms  of  the  support  that  will  be  provided  to 
them,  and  give  preference  to  those  products  that  enhance  the  strategy, 
while  making  allowance  for  special  cases  and  for  a  smooth  transition 
period . 

*  Equipment  which  does  not  comply  with  the  architecture  will  be  phased  out  as 
its  useful  life  ends,  to  be  replaced  with  standard  equipment.  Only  this  way 
will  cycles  of  dependency  be  avoided,  which  may  otherwise  perpetuate  the 
presence  of  non-standard  solutions. 


A. 2  Inter-Domain  Communication 

The  responsible  organisation  of  each  domain  has  to  manage  a  planned  evolution 
towards  the  intra-domain  architecture  of  its  choice  and  design.  The  CEC 
implementation  is  described  in  sections  4.3  to  4.5,  and  in  section  5  for 
different  services . 
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To  realise  inter-domain  interworking,  a  compatible  evolution  of  the 
intra-domain  architectures  is  necessary.  To  achieve  this  compatibility,  there 
is  a  need  not  only  for  standards  to  be  defined,  but  also  for  users,  the 
hardware  and  software  industries,  and  the  PTTs  to  comply  with  them.  In 
particular,  the  PTTs  must  make  the  services  based  on  these  standards  available, 
notably  : 

Leased  lines 
Data  networks 
Telex  and  Teletex 
Public  Electronic  Mail 
Videotex  Services 
Teleconferencing 

It  is  proposed  to  use  the  most  advanced  public  services  for  inter-domain 
communication  on  condition  that  harmonised  implementation  throughout  Europe  is 
available  within  the  required  time-frame.  Where  this  is  not  the  case,  the  same 
service  will  have  to  be  organised  by  direct  inter-domain  cooperation  of 
telecommunications  centres  using  public  data  networks  or  leased  lines.  For  such 
cases,  the  CEC  proposes  to  its  partners  the  same  standards  implementation  for 
inter-domain  communication  as  it  has  adopted  for  intra-domain  LSU/CSU 
communication  (see  section  4.3  and  section  5). 

In  the  organisation  of  inter-domain  communication,  telecommunication  centres 
(see  5  4.3)  play  an  essential  role.  Consequently,  telecommunication  domain 
managers  should  meet  to  agree  on  common  conventions  and  to  prepare  a  common 
customer  position  with  respect  to  public  services. 


4.3  Intra-Domain  Communication 

In  this  section,  the  three  entities  that  provide  the  interconnection  of 
equipment  within  a  domain  are  considered  : 

*  The  Domain  Communication  Network  (DCN)  which  links  the  LSUs  and  the  CSUs, 

*  The  Local  Communication  Network  (LCN)  which  links  the  equipment  of  an  LSU, 

*  The  Telecommunications  Centres  which  oversee  communications  on  the  DCN  and 
provide  a  gateway  between  the  DCN  and  the  public  networks,  or  the  networks 
of  other  domains. 

In  addition  to  interconnection,  the  principles  of  information  exchange  are 
considered  in  this  section  consisting  of  : 

*  Remote  Interactive  Communication  and 

*  File  and  Job  Transfer. 

User  services  will  be  discussed  in  section  5.  A  more  detailed  discussion  of  the 
standards  profiles  adopted  is  given  in  the  annex. 

To  provide  the  connections  necessary,  both  the  DCN  and  the  LCN  will  use 
different,  but  coexisting,  communication  technologies  for  some  time. 
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The  Domain  Communication  Network  IDCN)  must  eventually  achieve  integration  with 
the  ISDN  (Integrated  Services  Data  Network).  Before  this  integration,  it  will 
use  a  PSDN  (Packet  Switched  Data  Network),  the  private  CSTN  (Circuit  Switched 
Telephone  Network),  leased  lines  and,  possibly,  LAN  technology  for  single  large 
buildings. 

Within  the  Local  Communication  Network  ( LCN I ,  the  evolutionary  introduction  of 
coexisting  technologies  will  ensure  workstation  and  interhost  communication. 
This  will  start  with  direct  connections  of  terminals  to  local  hosts,  continue 
with  interhost  connections  by  the  PSDN,  and  finally  end  up  with  LAN  technology 
and  pre-ISDN  digital  exchanges. 

Except  for  urgent  cases,  the  general  introduction  of  LAN- technology  will  be 
based  on  a  competitive  range  of  products  supporting  international  standards. 
The  first  implementation  of  LAN  will  be  using  Ethernet  technology  because  this 
is  the  most  widely  spread  to  date,  and  well  supported  by  CEN/CENELEC  functional 
standards  profiles.  This  does  not  include  cheap  LAN  products  with  V24  interface 
for  workstation  to  local  host  communications. 

Remote  interactive  communication  lags  far  behind  other  fields  in 
standardisation.  The  long  awaited  ISO  Virtual  Terminal  Protocols  are  far  from 
approaching  definition,  and  seem  to  pursue  a  moving  target.  At  the  same  time, 
an  important  class  of  commercially  available  terminals  is  sufficiently  close  to 
conformance  with  a  subset  of  existing  ISO  standards.  It  is  thus  important  that 
the  standards'  committees  decide  on  an  intermediate  standard  subset  which  is 
close  to  general  current  practice  ;  otherwise  software  suppliers  will  continue 
to  develop  products  interfacing  with  proprietary  protocols  and  hardware 
suppliers  will  keep  their  customers  captive  to  their  product  range.  This  is  yet 
another  example  from  a  class  of  interconnected  standardisation  issues  for  which 
if  no  solution  is  found  soon,  the  overall  purpose  of  the  standardisation 
process  is  put  at  risk. 

A  proposal  of  a  feasible  approach  is  explained  in  the  annex.  Until  a  solution 
is  found,  ad-hoc  and  awkward  solutions  in  the  form  of  multiprotocol  converters 
are  forced  upon  the  architecture  (see  section  4.4)  which  must  only  be 
temporary . 


File  and  Job  Transfer  between  different  computers  in  the  Commission  has  become 
an  urgent  user  need.  As  a  result,  the  Multilateral  File  Transfer  System  (MFTS) 
has  been  developed  with  references  to  NIFTP  and  ECMA  standards  on  X.25 
networks . 

MFTS  is  available  on  BS2000  (Siemens),  VME  (ICL)  and  MS-DOS  computers.  MFTS 
will  be  available  on  UNIX-V  in  early  1987,  on  MVS  (compat.IBM)  in  mid-1987  and 
on  GCOS-8  (BULL)  in  1908. 

MFTS  will  be  replaced  by  ISO-FTAM  (File  Transfer,  Access  8*  Management)  and  by 
ISO-JTM  (Job  Transfer  h  Manipulation)  as  soon  as  these  standards  are  available 
in  products. 
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The  functionality  of  MFTS,  FTAM,  and  JTM  is  as  follows  : 
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Telecommunication  Centres  (TC)  have,  as  their  primary  role,  to  provide  central 
services  and,  possibly,  control  over  communications  oriented  operations.  The 
precise  definition  of  the  functions  of  the  TCs  after  the  introduction  of  ISDN 
is  beyond  the  time  horizon  of  this  document.  They  may  include  such  functions 
as : 


Communication  servers  for  the  Domain  Communication  Network,  such  as  for 
electronic  mail  (see  section  5.4) 

Gateways  between  the  DCN  and  the  public  communication  networks  (PCN) 

An  integration  between  different  communication  carriers  until  such  time  as 
a  proper  integrated  service  can  be  implemented  (ISDN) 

Network  management  servers 

Ante  servers  (see  section  5.1). 

Telecommunications  centers  will  use  computers  with  fast  processing  capacity  for 
filtering,  fast  temporary  storage  (buffering)  and  less  emphasis  on  long  term 
mass  storage  capacity. 
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4,4  Local  Support  Units 


Conformant  to  the  policy  of  prefering  products  which  enhance  the 
transportability  of  servers,  is  a  decision  to  limit  proprietory  operating 
systems  ,  and  not  to  introduce  new  ones  unless  they  are  generally  available  on 
equipment  of  several  manufacturers.  Of  such  operating  systems,  MS-DOS  and  UNIX 
have  been  selected  ;  the  former  for  single  user  hosts  (workstations),  and  the 
latter  for  single  -  and  multi-  user  hosts. 

In  the  case  of  UNIX,  portability  is  further  enhanced  by  the  formation  of  the 
X/OPEN  group  of  manufacturers  specifying  a  standard  definition  of  the  interface 
to  the  UNIX  operating  system  .  As  this  standardised  interface  is  primarily  to 
ensure  the  portability  of  applications,  preference  is  given  to  softwares  whose 
interface  with  the  host  environment  conforms  to  that  defined  by  the  X/OPEN 
specifications.  Cooperation  will  allow  the  definitions  to  be  extended  to  new 
pertinent  areas  such  as  the  support  of  extended  multi-lingual  character  sets. 

This  is  expected  to  have  a  profound  effect  on  the  configuration  of  LSU 
resources,  as  they  will  for  their  greatest  part  consist  of  new  installations. 
However,  this  policy  does  not  preclude  the  installation  on  non-UNIX  systems  on 
LSUs.  Non-UNIX  systems  will  continue  to  be  installed  as  long  a  continuity  needs 
to  be  preserved  with  existing  servers  based  on  proprietory  operating  systems. 

Selection  of  software  has  a  much  more  important  impact  on  hardware  selection 
than  it  has  ever  had  in  the  past.  Software  packages  can  contribute  to  a  drastic 
decrease  in  the  cost  of  developing  complete  applications  and  acceleration  of 
their  use  is  economically  expedient.  Such  packages  should  be  available  on  as 
many  systems  as  possible. 

A  coherent  set  of  software  products  that  should  be  selected  for  the  LSUs  should 
provide  servers  for  the  following  functions  : 

-  Ante-Server  (see  section  5.1) 

-  Text  processing 

-  Data  Entry 

-  File  Server 

-  Structured  Data  Bases 

-  Document  Dtat  Bases 

-  VTX  Data  Bases 

-  Thesaurus 

-  Data  Dictionary 

-  Print  Servers 

-  Report  Writer 


-  Mail  Server 

-  Business  Graphics 

-  Advanced  Graphics 

-  Cartography 

-  Document  Composition 

-  Statistics 

-  Spreadsheet 

-  Desktop 

-  Compilers/ Interpreter s 

-  Screen  Formatting 

-  etc.  . . 
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To  economise  on  the  human  resources  required  for  training  and  user  support,  it 
is  necessary  to  limit  unnecessary  redundancy  in  the  packages  to  fulfill  these 
functions.  Equipment  that  cannot  support  selected  packages,  therefore,  stands  a 
smaller  chance  of  being  acceptable,  despite  its  intrinsic  merits  as  a  product. 

The  tasks  that  need  to  be  carried  out  within  a  local  user  community  should  be 
appropriately  distributed  between  local  and  personal  computers  :  the  higher  the 
requirement  from  a  server  interactivity  and  immediate  response,  the  more  it 
ought  to  reside  on  a  personal  host  ;  requirements  of  common  access  to  data,  on 
the  other  hand,  will  dictate  the  location  of  a  server  on  a  local  host. 

For  the  user  to  feel  at  home  independently  of  the  host,  or  even  the  software 
being  used,  standardisation  of  the  user  interfaces  is  important,  whenever 
possible,  in  different  classes  of  application.  Thus  : 

SQL  is  adopted  as  the  standard  interface  to  relational  databases  ; 

CCL  for  documentary  databases,  enhanced  by  a  system  of  menus  ; 

It  would  be  desirable  to  adopt  such  widely  acceptable  interfaces  in  the  areas 
of  graphics,  and  end-user  programming  languages.  APL  is  widely  used  as  an 
end-user  programming  language,  but  it  is  not  suitable  for  all  purposes,  at  the 
same  time,  4th  Generation  Languages  are  too  new  to  have  established  themselves, 
let  alone  be  moving  towards  standard  interfaces. 

The  end  user  should  also  have  available  the  means  of  printing  close  to  the 
workstation,  at  least  for  draft  quality  printing.  Higher  quality  printing  will 
generally  be  available  through  printer  servers  residing  on  local  hosts. 

Necessary  conditions  to  reach  the  desired  target  are  : 

the  removal  of  proprietory  terminals,  permitting  the  principles  of  a  single 
integrated  workstation  to  be  implemented  in  a  standard  way  (see  Annex) 
the  introduction  of  cost  effective  technology  for  the  efficient 
implementation  of  the  LCN. 
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*  Fig.  07  :  In  the  short  term,  a  proprietory  multi-protocol  converter 

(MPC )  installed  at  the  CSU  and  ISU  levels  will  permit  the 
connection  of  standard  terminals  to  the  CSU  hosts,  to  UNIX 
and  non-UNIX  hosts.  For  the  connection  of  workstations  to 
hosts  within  an  LSU,  cheap  LANs  based  on  V24  interfaces  may 
also  be  used. 

*  Fig.  07  bis  :  As  equipment  is  phased  out  the  following  changes  take  place: 

PADs  disappear  with  terminals  accessing  the  DCN  via  the  UNIX 
computers  ; 

Word  processing  equipment  is  replaced  by  PCs  ; 

Access  to  non-UNIX  computers  in  an  LSU  is  carried  out 
entirely  through  PCs  or  standard  terminals  ; 

PCs  cease  to  be  connected  directly  to  the  PSDN,  MFTS  being 
available  on  UNIX. 

*  Fig.  07  ter  :  LANs  are  introduced  resulting  in  : 

UNIX  local  computers  without  workstations. 

The  connection  of  PCs  on  the  LAN  for  sharing  resources 
The  MPC  becomes  a  server  with  a  standard  interface  towards 
the  LAN  and  a  proprietory  interface  towards  the  non-UNIX 
local  computer 

A  gateway  between  the  LCN  and  the  DCN  is  introduced. 

*  Fig.  07  quatro  :  The  target  is  reached,  and  the  MPCs  removed,  once  a 

functional  standard  exists  and  is  implemented  for  the 
connection  of  standard  terminals  to  the  non-UNIX  local 
computers . 

The  importance  of  pass-through  facilities  cannot  be  over-emphasised. 


4.5  Common  Support  Units 

The  components  through  which  a  Common  Support  Unit  provides  its  services  are 
mostly  large  computer  hosts  with  fast  processors  and  substantial  storage 
capacity  for  central  databases,  as  well  as  appropriate  channels  of 
communication . 

There  are  two  main  types  of  CSU  : 

-  Computer  Centres 

-  Telecommunication  Centres  (see  4.3). 
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Many  heterogeneous  systems  are  likely  to  be  present  for  the  foreseeable  future 
of  mainframe  installations  across,  as  well  as  within  domains.  The  disadvantage 
of  heterogeneity  is  reduced  (whether  the  user  is  in  the  same  domain  or  not)  by: 

Adoption  of  "standard"  application  software  on  as  many  installations  as 
possible  providing  the  user  with  a  consistent  interface  ; 

Adoption  of  standard  intra-domain  communication  on  all  installations,  as 
explained  in  section  4.3  and  4.4  fig  07  ; 

A  high  speed  channel  connecting  processors  and  allowing  the  resources  of 
.  one  computer  to  be  accessed  via -another  one. 

In  the  CEC,  the  following  mainframe  operating  systems  will  be  supported  by  the 
intra-domain  communication  explained  in  4.3  : 

ICI  :  VME 

SIEMENS  :  BS  2000 

IBM  :  VM/CMS  on  AMDAHL 

IBM  :  MVS  on  AMDAHL 

BULL  :  GC0S8 

The  most  important  general  application  software  for  which  maximum  coverage  is 
persued  in  the  CEC  includes  :  ADABAS/NATURAL-SAS  -  MISTRAL-BASIS.  Videotex  type 
servers  will  be  added  as  soon  as  selection  procedures  are  completed. 

Standard  user  interfaces  implementing  CCL  (Common  Command  Language),  SOL  and 
menu  driven  access  will  be  generalized  for  all  textual  and  numerical  data  base 
systems . 

Foe  the  future,  the  main  mission  of  the  Computer  Centre  will  be  to  set  up  and 
operate  the  infrastructure  for  an  Information  Dissemination  Service  (IDS  -  see 
section  5.3). 


5.  IMPLEMENTATION  OF  SERVICES 
5.1  User  Agent  Service  (UAS) 

A  user  of  the  informatics  architecture  generally  accesses  servers  and  interacts 
with  them.  In  so  doing,  the  user  is  faced  with  a  formidable  array  of  interfaces 
as  shown  iri  the  diagram  below  (User  A)  : 
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This  complexity  doer,  not  need  to  be  that  high  because  the  choices  of  the  user 
at  any  one  time  are  generally  limited  to  those  of  the  object  at  hand  ;  for 
example,  access  to  a  database  for  information  on  a  particular  subject  :  the 
user  does  not  know  on  which  host  the  information  he  is  interested  in  resides, 
nor  does  he  remember  the  procedures  necessary  to  log  into  the  appropriate  one. 


To  simplify  the  user  interface,  there  will  exist  a  User  Agent  Service  (UAS) 
which  will  act  as  an  "agent  of  the  user"  vis-a-vis  the  appropriate  servers. 
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These  servers  may  reside  on  different  heterogeneous  hosts  which  may  belong  to 
different  domains. 

The  User  Agent  Service  is  implemented  through  ante-servers  (AS).  An  ante-server 
is  a  piece  of  software  which  interacts  with  the  user,  and  acts  on  the  user’s 
behalf  in  interacting  with  the  appropriate  target  servers. 

The  ante-server,  therefore  : 

Gives  the  user  guidance  in  finding  the  location  of  the  appropriate  service; 

Acts  on  the  user's  behalf  to  establish  an  appropriate  connection  and, 
possibly,  provide  translation  services  in  formulating  the  user's  query  in 
terms  that  the  entry  server  will  understand  ; 

Provides  access  control  to  services  (identification/authentication)  ; 

Collects  service  accounting  data  of  the  resources  used. 

An  ante-server  behaves,  with  respect  to  a  target  service,  as  if  it  were  the 
user.  The  other  servers  it  interacts  with  are  not  aware  of  its  existence.  Thus, 
the  ante-server  can  be  the  user  of  another  ante-server,  and  of  course  have 
other  ante-servers  as  users.  We  can,  therefore,  distinguish  a  hierarchy  of 
ante-servers  as  follows  : 

-  Common  ante- server s 

-  Local  ante-servers 

-  Personal  ante- servers 

This  hierarchy  is  shown  in  the  example  diagram  below  : 
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0  =  Server 
IS  =  Entry  Server 
IS  =  Ante  Server 


DEB  =  User  Agent  Serv. 
EGB  =  Service  1 
05  =  Service  2 
S3  =  Service  3 
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In  this  diagram,  the  user  interacts  with  an  ante-server  (AS)  on  the  host  on 
which  he/she  is  immediately  connected.  Through  a  cooperation  of  possibly  many 
ASs,  Hentry  servers”  (ESs)  are  accessed  on  the  appropriate  hosts.  These  may  be 
the  target  servers  or  they  may  invoke  other  directly  cooperating  servers  on  the 
same  or  different  hosts  providing,  in  the  example  above,  three  services  (SE1  to 
SE3 ) . 

The  personal  ante-server  is  likely  to  exist  if  only  to  limit  the  choices 
available  to  the  user,  for  example  by  effecting  a  direct  connection  with  a 
local  ante-server. 

Access  control  and  accounting  will,  of  course,  be  more  developed  for  the  common 
ante-servers. 

A  central  ante-server  with  dedicated  host  will  be  part  of  the  Telecommunication 
Centre  and  will  manage  the  intra-  and  inter-domain  connection  calls  to  all 
other  ante-servers. 

To  achieve  the  desired  tasks,  an  ante-server  will  have  access  to  2 

Information  on  users  (user  profiles)  relating  to  access  control  and 
technical  competence, 

Information  on  the  target  servers  and  their  environment. 

These  will  be  stored  in  databases  describing  services  and  users  which  will  be 
available  to  the  administrator  of  the  User  Agent  Service. 

User  Agent  Services  must  be  accessible  by  standard  screen  mode  terminals. 


5.2  Information  Production  and  Administration 
These  are  the  services  which  : 

Help  the  user  produce  information  for  his/her  own  use,  or  for  use  by 
others.  Production  can  be  original  (e.g.  text  processing),  or  it  can 
consist  of  ’  the  modification  of  existing  information  to  produce  new 
information  (decision  support  systems,  the  information  necessary  to  update 
a  data  base ,  etc. ) . 

Help  management  to  administer  the  information  produced  by  registering  the 
information  produced  (such  as  documents)  with  unambiguous  identifiers, 
relating  it  to  other  items  of  information  for  easier  future  retrieval  and 
follow  up  of  actions. 

For  the  production  and  administration  of  information,  the  data  are  stored  in  a 
production  data  base.  The  rbsourtes  takO  the  form  of  processing  and  storage 
capacity  through  servers  on  any  type  of  hosts. 

Depending  on  whether  the  user  maintaining  and  accessing  the  information  is  the 
individual  user,  the  local  uset 1  cdtfwhunity  or  a  group  spread  over  different 
local  user  communities,  the  production  data  base  will  be  personal,  local  or 
common. 
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For  personal  and  local  production  data  bases,  the  Local  Support  Unit  will 
provide  the  necessary  resources  (see  section  4.4)  •  Common  rules  for  office 
procedures,  document  administration,  terminology  and  office  document 
architecture  (OOA)  must  assure  communication  of  information  between  local  user 
communities. 

Common  production  data  bases  are  maintained  in  the  Computer  Centre  (see  section 
4.5).  An  important  special  case  is  the  central  archiving  of  non-active  local 
information  that  has  to  be  maintained  for  the  whole  organisation. 

5.3  Information  Dissemination  Service  (ID5) 

Numerous  databases  currently  exist  in  the  European  Institutions,  containing 
large  amounts  of  information.  The  potential  usefulness  of  this  information  is 
not  fully  exploited  because  : 

Access  procedures  are  difficult  ; 

Retrieval  languages  are  difficult  to  use  and  vary  from  one  system  to 
another  ; 

Data  bases  are  designed  to  fit  local  and  limited  usage.  They  are  production 
data  bases  rather  than  dissemination  data  bases  ; 

Information  about  existing  information  is  insufficient. 

To  overcome  this  barrier,  new  data  bases  will  be  created  whose  aim  will  be  to 
give  easy  access  to  the  information  needed  by  a  specific  user  group.  Such 
systems  are  called  dissemination  data  bases  (ODD).  They  must  appear  to  the  end 
user  as  a  single  data  base,  even  if  different  DBMS  and  different  data  bases  are 
used  to  satisfy  the  needs  of  a  user  group.  The  content  of  dissemination  data 
bases  is  built  up  of  extracts  from  production  or  other  dissemination  data 
bases.  Common  DDB  are,  by  definition,  located  on  CSU’s  (Computer  Centre). 

An  Information  Dissemination  Service  (IDS)  is  a  service  which  presents  a  set  of 
tools  and  an  organisational  framework  for  the  creation,  maintenance  and 
interrogation  of  dissemination  data  bases.  IDS  offers  : 

standard  data  base  formats  for  specific  types  of  information  :  for  example, 
standard  descriptions  and/or  presentation  for  bibliographic  information  - 
likewise  for  statistical,  legal  and  terminological  information  ; 

standard  facilities  to  feed  the  DDB.  These  include  interfaces  between 
production  and  dissemination  databases,  interfaces  between  DOS  and  other 
data  sources,  such  as  Telex/Teletex ,  text  processing  or  photocomposition 
tapes,  and  direct  data  entry  ; 

a  user-friendly  interface  for  information  access  and  manipulation, 
explaining  itself  and  adaptable  to  specific  user  needs.  The  interface  is 
not  limited  to  a  single  data  base,  but  includes  all  databases  of  interest 
to  a  user  group.  It  should  be  harmonised  with  the  UAS  user  interface 
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interfaces  and  tools  to  produce  extracts  of  data  bases  on  magnetic  tapes, 
read-only  optical  disk  media  (CD-ROM),  micro-fiche  or  paper,  or  to 
down-load  data  onto  a  local  computer,  and  distribute  documents  by 
electronic  mail  ; 

facilities  describing  the  information  that  is  available. 

Defining  and  implementing  standards  is  an  essential  element  within  IDS  and  is 
required  at  three  levels  : 

Standards  for  the  structuring  of  information.  A  homogeneous  user  interface 
and  automatic  data  exchange  are  impossible  without  standard  rules  for 
information  structuring  and  formatting.  Examples  of  existing  standards  are 
CCF ,  UN  I S I  ST  and  FORMEX. 

Exchange  standards  are  to  be  based  on  more  technical  standards  which  do  not 
describe  the  content  of  the  information,  but  only  the  technical  format.  For 
example,  the  representation  of  documents  containing  an  unlimited  number  of 
variable  length  fields  is  defined  in  ISO  2709.  The  implementation  of  such 
standards  will  decrease  the  effort  of  developing  specific  interfaces 
considerably . 

Standards  for  a  unique  presentation  of  screens  and  menus.  Although 
different  data  management  software  might  be  used  for  a  single  DDB,  the 
system  should  appear  to  be  based  on  a  single  homogeneous  software  system. 
Standard  rules  for  dialogue  and  screen  design  must  thus  be  applied  to  all 
sub-systems  of  IDS  as  well  as  to  UAS  and  possibly  to  other  services  having 
a  large  user  population. 


5.4  Electronic  Mail 

Electronic  Mail  should  allow  messages  (documents)  of  various  formats  to  be 
interchanged  between  users  in  the  same  domain,  as  well  as  between  users  in 
different  domains,  including  ones  outside  the  European  Institutions. 

Electronic  Mail  will  be  based  on  the  Message  Handling  System  standards,  as 
developed  by  the  CCITT  and  ISO  (MHS/MOTIS). 

Until  such  time  as  MHS  products  are  available  on  the  hosts  selected  for  the 
present  architecture,  electronic  mail  will  be  based  on  Teletex  protocols 
supplemented  with  a  message  header,  derived  from  and  equivalent  in  scope  to  the 
CCITT  X-430  recommandations . 

This  initial  implementation  of  electronic  mail  will  allow  urgent  needs  to  be 
met  while,  at  the  same  time,  it  will  ensure  that  the  technical,  human  and 
administrative  infrastructure  is  ready  to  receive  MHS  products  when  they  are 
available . 

For  economical  reasons,  and  in  view  of  the  transient  nature  of  the  early 
implementation,  it  is  not  envisaged  that  each  workstation  should  be  furnished 
with  the  Teletex  interfaces  necessary  to  implement  electronic  mail.  Instead, 
these  will  be  concentrated  on  local  servers. 
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The  development  of  electronic  mail  services  is  being  carried  out  in  the 
framework  of  INSIS,  and  will  be  based  on  the  relevant  European  Norms  being 
defined  by  CEN-CENELEC  and  CEPT. 

This  development  recognises  the  importance  of  the  exchange  of  revisable 
documents  within  the  context  of  electronic  mail  services.  It,  therefore, 
enriches  the  repertoire  of  standards  on  which  these  services  are  to  be  based  by 
proposing  compliance  with  an  Office  Oocument  Architecture.  This  is  the  ODA/ODIF 
standard  from  ISO  (DP  0613),  the  kernel  of  which  is  sufficiently  stable. 

The  diagram  below  shows  the  distributed  nature  of  electronic  mail  : 


UA  =  User  Agent 
MTA  =  Message  Transfer  Agent 
DSA  =  Directory  Service  Agent 
SMA  =  System  Management  Agent  Diag.10 


The  user  interacts  with  a  user  agent  (UA)  to  create  or  receive  messages.  The  UA 
liaises  with  a  Directory  Service  Agent  (DSA)  to  associate  the  names  of  other 
users  of  the  electronic  mail  service  with  their  addresses.  This  ends  up  in  the 
creation  of  an  "envelope"  which  is  submitted,  with  the  message,  to  the  Message 
Transfer  Agent  (MTA).  Messages  are  relayed  across  MTAs  until  they  reach  the  UA 
of  the  recipient.  An  MTA  uses  the  services  of  a  System  Management  Agent  (SMA) 
which  provides  management  tools  and  referral  services. 

There  should  only  be  a  single  MTA  and  a  single  SMA  in  each  LSU.  Directory 
Service  Agents  and  User  Agents,  on  the  other  hand,  are  ideally  distributed  to 
the  workstations  because  they  are  directly  related  to  the  end  user.  Directory 


35 


Services  will,  however,  be  provided  at  higher  levels  also,  through  the 
electronic  mail  server  of  an  LSU  or  the  Telecommunications  Centre  for 
domain-wide  or  extra-domain  information. 

A  central  DSA  is  maintained  in  the  TC,  whose  MTA  will  act  as  a  gateway  to  the 
electronic  mail  services  of  other  domains.  Conversion  between  the  text  formats 
supported  by  the  electronic  mail  service  (IS0646,  IS06937  and  ISO  OP/8613  when 
finalised)  is  carried  out  at  the  MTA  level.  Conversion  to  one  of  these 
standards  from,  say,  the  internal  format  of  a  word-processor,  is  carried  out  by 
the  UA. 

The  services  covered  are  : 

Communication  with  other  private  domains  via  the  X25  public  services,  using 
common  conventions  defined  by  the  CEN/CENELEC  functional  standard  A/3211  ; 

Communication  with  users  of  the  MHS  services  provided  by  the  PTTs, 
following  the  CEPT  A/311  functional  standard  ; 

Communications  within  the  domain. 

In  implementing  the  electronic  mail  service,  the  following  principles  are  to  be 
followed  : 

Standard  protocols  will  be  used  for  the  interchange  of  text  over  the  DCN . 
These  will  be  the  P1/P2  protocols  defined  in  the  CCITT  X.400  series  of 
recommendations  ; 

A  standard  access  protocol  (P7)  will  be  used  to  access  the  electronic  mail 
services.  Pending  the  availability  of  this  protocol,  commercially  available 
solutions  will  be  used  ; 

To  deal  efficiently  with  the  traffic  that  will  be  generated,  the  aim  should 
be  to  carry  out  communication  with  the  MTA  within  an  LSU  over  a  LAN  when 
this  is  feasible,  and  to  dedicate  a  host  to  an  MTA  when  this  is  justified. 


5.5  Application  Services 

These  services  differ  from  the  others  in  two  ways  : 

the  level  at  which  they  operate.  They  tend  to  deal  with  a  specialist  area 
related  to  a  topic  of  interest  to  one  or  more  administrative  section  of  the 
organisation  ; 

their  dependence  on  other  services  in  carrying  out  some  of  their  functions, 
as  well  as  the  lack  of  dependence  of  other  applications  on  them  :  they  are 
the  top  of  a  hierarchy. 

Although  application  services  are  by  far  the  most  important  category  of 
services,  as  well  in  number,  in  size  of  data  bases  and  the  total  development 
cost,  there  is  very  little  to  add  for  them  from  architectural  point  of  view. 
They  have  to  follow  all  the  rules  set  out  in  this  document  and  rely  as  much  as 
possible  on  the  other  services. 
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6.  OSI  -  STANDARDS  PROFILES 


6 . 1  Evolution 

A  complete  and  coherent  set  of  standards  profiles ,  specifying  options  and 
intercepts,  is  necessary  at  all  times  for  the  implementation  of  an 
architecture.  The  table  below  presents  a  synthesis  of  these  profiles.  Some 
important  subjects  are  absent  from  this  table.  These  are  subjects  for  which 
neither  an  immediate  standard  solution  is  available  nor  is  there  enough 
information  or  experience  for  a  decision  on  intercepts  to  be  taken.  These  will 
be  covered  in  the  next  edition  of  the  Guidelines,  and  include  the  introduction 
of  ISON,  LANs  for  the  Domain  Communication  Network  (DCN),  and  LANs  other  than 
Ethernet. 

The  table  shows  that  it  is  possible,  today,  to  implement  a  coherent 
architecture  with  almost  no  proprietory  protocols.  The  only  important  exception 
is  interactive  communication. 

The  evolution  towards  an  ideal  world  of  open  systems  has  a  vertical  and  a 
horizontal  component  : 

Progress  in  the  vertical  sense  takes  place  at  the  Transport  Layer  of  the 
OSI  model.  Services  which  were  previously  built  directly  on  the  Network 
layer,  now  need  to  be  lifted  upwards  to  the  Transport  layer,  becoming  thus 
network  independent  (with  the  exception  of  X29) 

Horizontal  progress  takes  place  as  intercept  profiles  are  replaced  by  OSI 
profiles  as  soon  as  they  become  available.  This  migration  is  shown  by  the 
arrows  in  the  upper  layers  of  the  table  below. 

The  combination  of  both  a  horizontal  and  a  vertical  evolution  at  the  transport 
layer  is  the  reason  why  this  layer  is  shown  twice  :  the  evolution  of  the 
networks  is  towards  a  fully  standardised  OSI  Transport  Layer  (4),  while  some 
services  will  temporarily  have  to  rely  on  the  X-29  protocol  or  MPC  which 
communicate  directly  with  X-25  at  the  Network  Layer  (31. 
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|  INTERACTIVE  COMMUNICATION 
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The  services  specified  by  the  columns  of  the  upper  table  should  be 
able  to  access  the  networks  at  the  places  where  their  layer  4 
(Transport)  appears  in  the  lower  table.  The  two  tables  are 
horizontally  independent. 
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6.2  Network 

ohf\SriSsi  mode?njnati°n-IIetW^k  ,DCN)  Sh°Uld  be  connectio"  oriented  at  layer  3 
and  annr!nrO^  *  provide  the  necessary  security,  access  management  controls 
p  fef.®  resource  allocation.  Moreover,  a  unique  addressing  scheme 
control1"9  Sh°Uld  b9  available  on  the  0CN  t0  ensure  the  necessary  routing 


inttrho«r°9niSedth!^  LAN  implementation  may  imply  connectionless  (CL)  local 
interhost  communication  at  layer  3  (transport  class  4)  whereby  the  LSU  is 

considered  by  the  DCN  as  a  distributed  end-system.  LCN  therefore  must  H 

bp  y5^i^isot^:dirom1the  °cN- and  “«t.  through;  i:;”f#/:i-r“::bS 

senar.L  fh  ™  *  S°  necessary  for  security  reasons  and  in  order  to 

p  rate  the  responsibilities  for  access  and  resource  control  taken  by  the 

Pieces  ofSLANS  Adm!"lstrato;r;.  V  diStinct  from  the  DCN  management.  Isolated 
Ler!  J  fh  ’  Same  LCN  ,e'9'  f0r  9e°9raphically  separated  equipment  and 

OCN  Of  bourse6  Wll\b®  linked  by  LAN'bridges  and  not  through  the 

DCN.  Of  course,  this  does  not  restrict  the  exceptional  cases  of  LSUs 

sinaieP°ndtn?  \°  dlspersed  communities,  such  as  international  committees,  or 

public  networks  n  ^  COmmunicate  directlV  through  the  DCN,  and/or  the 

The  possible  coexistence  of  direct  end-to-end  communication  using  different 
transport  classes  (class  0  and  2  at  one  end,  with  class  4  at  the  o?her)  needs 
at  level  3  and/  the  l-SU-gateway .  For  this  reason,  the  structuring  of  layers 
imnori a nr o  V"d/°r  *  for  811  operational  services  has  become  of  '  vital 
I  r  ;  IS  a  particular  problem  for  three  important  basic  services: 

interactive  communication,  file  and  job  transfer,  and  message  handling. 


6.3  Interactive  Communication 

Interactive  line  mode  communication  is  implemented  using  the  X-29  protocol  and 
the  SIC-S1  specifications  over  the  packet  switched  (X25)  network.  This  type  of 
communication  will  not  evolve;  instead  it  will  be  phased  out  and  replaced  by 
screen  mode  communication. 

However,  the  X29  protocol  has  to  be  supported  on  LANs  to  give  access,  in  line 
mode,  to  either  local  or  common  hosts.  PAD  emulators  on  local  and  personal 
computers  may  be  implemented  on  either  : 

connection  oriented  LAN  over  the  ISO  network  protocol  (ISO  8208)  without 
any  transport  protocol,  or 

connectionless  LANs  over  the  class  4  Transport  protocol  (ISO  8073)  ;  in 
this  case,  the  X25/LAN  gateway  must  provide  the  necessary  adaptation  to 
carry  over  the  connection  to  hosts  which  use  the  X29  protocol  over  X25 
without  any  Transport  protocol. 


Interactive  screen  mode  communication  between  workstations  and  local  or  common 
servers,  based  on  standard  profiles,  is  very  difficult  to  implement  because  : 

The  long  awaited  Virtual  Terminal  Protocols  (VTP)  are  still  too  far  from 
being  agreed  to  be  considered  for  implementation  ; 
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The  widely  available  CCITT  X-29  protocol  does  not  conform  with  the  OSI 
model.  In  addition,  it  relies  on  X-25  at  layer  3  and  not  on  transport 
protocols  ; 

-  The  existing  ISO  standards  te.g.  ISO  6*29)  cover  too  wide  a  range  of 
functions  on  one  hand,  while  on  the  other  they  do  not  include  advanced 
features  such  as  graphics,  nor  they  do  not  define  all  necessary  function 
elements  required  by  the  OSI  model.  Commercially  available  terminals  and 
software  products  offer  different,  and  often  incompatible,  subsets  of  these 
standards . 

To  support  MPCs  on  LANs,  a  solution  entirely  parallel  to  the  one  suggested  for 

X-29  above  must  be  adopted. 

The  planned  scenario  for  screen  mode  communication  has  to  resolve  two  issues  : 

1.  The  interworking  of  the  terminal  and  its  access  point,  which  may  be  located 
on  a  personal  or  local  computer.  It  is  proposed  to  adopt  a  standard  which 
is  a  proper  subset  of  already  approved  ISO-standards  while,  at  the  same 
time,  close  to  the  de-facto  implementation  of  a  sufficiently  competitive 
range  of  commercially  available  terminals.  Such  a  subset  is  defined  in 
SIC-S*  and  CEN/CENELEC  will  be  asked  to  consider  it  urgently  as  an  interim 

standard . 

The  ISO-subset  proposed  by  SIC-S4  is  based  on  a  compromise,  whereby  a 
limited  functionality  (VT200-like)  is  supported  for  remote  communications 
(CSU-LSU  and  inter-domain),  whereas  higher  functionality,  such  as  graphics 
and  image,  is  temporarily  restricted  to  personal  computers  and 
communication  with  local  computers.  The  SIC-S4  definition  of  the  ISO-subset 
includes : 

4x96  characters  with  upper/lower  case,  accented  latin  and  greek 
(optional),  current  and  special  symbols,  mosaic  and  colour 
(optional) . 

Cursor  movements/tabulation/editing 
Screen  size  24x80 

SIC-S4  also  defines  lower  levels  of  funcionality ,  corresponding  with 
VTIOO-like  terminals  and  line  mode  terminals,  but  which  have  to  be 
supported  by  higher  level  terminals  too. 

2.  The  interworking  of  the  terminal  access  point  and  the  remote  host. 

To  address  this  problem,  it  is  proposed  to  define  a  functional  profile, 
called  Virtual  Screen  Mode  (VSM) .  which  again  should  be  based  on  existing 
standards  and  be  close  to  de-facto  implementations  of  terminals,  as  defined 
in  SIC-S4.  This  solution  is  technically  similar  to  the  one  presently 
implemented  with  Multi  Protocol  Converters,  with  one  fundamental  difference 
:  the  screens  transferred  over  the  network  will  conform  to  a  standard  and 
will  not  be  proprietary.  This  should  provide  an  incentive  in  the  market  for 
the  suppliers  of  application  softwares  and  terminals  to  line  up  to  this 
interim  standard,  instead  of  continuing  to  support  proprietary  protocols. 
It  is  most  important  that  CEN/CENELEC  should  start  working  in  this 
direction  urgently. 


40 


6.4  File  and  Job  Transfer 

Since  the  MFTS  developments  began  in  1982,  the  Transport  Station  has  been  based 
on  ECMA-72  class  0,  which  implied  no  Transport  class  negotiation.  This 
Transport  Station  suited  X-25  networks  well. 

To  allow  MFTS  to  exchange  files  between  a  host  connected  to  the  X.25  network 
and  a  host  connected  to  a  LAN,  some  adaptation  may  be  necessary  depending  on 
the  OSI  layer  at  which  a  Connection  Oriented  Service  is  provided  :  network  or 
transport  layer. 

If  the  Connectionless  Network  Service  (CL-NS)  is  used  on  the  LAN,  then  the 
functional  standard  ENV. *1.101  will  apply.  The  MFTS  end-system  on  the  LAN 
will  be  based  on  the  T/621X  profile,  while  the  MFTS  end-system  on  X.25  will 
be  based  on  T/311  profile.  Then,  the  X. 25/LAN  Relay  Function  will  be  based 
on  the  R/31X1  profile. 
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To  implement  this  solution,  the  Transport  Station  used  by  MFTS  systems  will 
need  to  be  adapted  :  the  LAN-MFTS  systems  will  have  to  support  a  class  * 
Transport  Station,  and  the  X.25-MFTS  systems  will  have  to  be  adapted  to  a 
class  0/2  Transport  Station  supporting  class  negotiation. 

If  the  Connection  Oriented  Network  Service  (CO-NS)  on  LANs  is  used,  then 
the  LAN-MFTS  systems  will  be  based  on  the  T/S11  profile  while  X. 25-MFTS 
systems  based  on  T/311  profile  ;  the  X. 25/LAN  gateway  will  be  based  on  the 
R/12  profile  (cf.  CEN/CENELEC  profiles). 
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In  this  solution,  both  LAN-MFTS  systems  and  X-25  MFTS  systems  can  remain 
unchanged  (except  for  the  network  service  interface  on  LAN)  using  the 
existing  ECMA-72  class  0  Transport  Station  without  class  negotiation.  To 
conform  fully  with  the  T/311  profile,  however,  the  Transport  Stations  on 
both  LAN  and  X.25  could  be  adapted  to  support  transport  class  0/2  and  class 
negotiation. 

MFTS  will  be  replaced  by  ISO  based  products  as  soon  as  these  are  able  to 
replace  the  MFTS  functionality. 


6 . 5  Message  Handling 

The  message  handling  system  will  eventually  conform  to  CCITT's  X400  series  of 
recommendations.  Its  implementation  is  divided  into  two  phases,  the  first  being 
ready  for  operation  end  1906. 

During  the  first  phase,  the  application  layer  will  consist  of  a  minimum 
envelope  sufficient  for  the  immediate  requirements,  and  similar  in  syntax  to 
that  defined  in  the  CCITT  X.430  recommendation.  During  the  second  phase,  it 
will  migrate  to  standard  envelopes  and  headers  as  defined  in  the  MHS/MOTIS 
model,  in  accordance  with  the  functional  profiles  defined  by  CEN/CENELEC/CEPT . 
The  document  body  will  conform  to  the  Office  Document  Architecture  and  Profile, 
as  defined  by  ISO.  A  stable  kernel  of  ODA  is  proposed  as  an  urgent  interim 
standard  for  CEN/CENELEC  approval  with  the  support  of  the  INSIS  community  as 
well  as  the  industry. 

The  presentation  and  session  layers  will  evolve  from  Teletex  based  encodings 
and  protocols  during  the  first  phase  to  those  required  by  the  X.400  series  of 
recommendations  during  the.  second  phase,  notably  the  connection  oriented 
presentation  and  BAS  session  and  conforming  to  the  relevant  profiles  defined  by 
CEN/CENELEC/CEPT. 

Tinally,  the  transport  layer,  which  will  again  be  based  on  the  Teletex  T70 
protocol  during  the  first  phase,  will  migrate  to  the  ISO  Transport  of  a  class 
appropriate  for  the  underlying  network  at  any  one  time. 
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6.6  References  to  Standards  Used  in  the  Tables 
6 • 1  Interractive  Communication 

*  MPC  "Multiple  Protocol  Converter"  (based  on  a  private  protocols) 

*  SIC  SI  :  CEC  SIC  SI  "Teletype  TTY  Compatibility  Requirements* 

*  SIC  S4  :  CEC  SIC  S4  "Screen  Mode  Terminal  Compatibility  Requirement" 

*  VSM  "Virtual  Screen  Mode"  (waiting  for  CEN/CENELEC  functional  standard) 

*  X3  "Packet  Assembly/Oisassembly  Facility  (PAD)  in  a  Public  Data  Network" 

*  X28  "DTE/DCE  Interface  for  a  Start-Stop  Mode  Data  Terminal  Equipment 

Accessing  the  Packet  Assembly/Disassembly  Facility  (PAD)  in  a  Public 
Data  Network  situated  in  the  same  Country" 

*  X29  "Procedures  for  the  Exchange  of  Control  Information  and  User  Data 

between  a  Packet  Assembly/Disassembly  (PAD)  Facility  and  a  Packet 
Mode  DTE  or  another  PAD 

6 . 2  File  and  Job  Transfer 

•*  ASN-1  "Abstract  Syntax  Notation  One"  /  ISO/DIS  882*. 2  -  ISO/DIS  8825 

*  CASE  "Common  Application  Service  Element"  /  ISO/DIS  8649 . 2- ISO/DI S  8650.2 

*  CO-Prs  "Connection  Oriented  Presentation"  /  ISO/DP  8822(2)-ISO/DP  8822(2) 

*  ECMA-72  Class  0  "Transport  Protocol"  January  1981 

*  FTAM  "File  Transfer,  Access  and  Management"  /  ISO/DP  8571 

*  JTM  "Job  Transfer  and  Manipulation"  /  ISO  8831  -  ISO  8832 

*  MFTS  "Multilateral  File  Transfer  System" 

CEC  File  Transfer  -  Facilities  based  on  NIFTP 

*  Session  BSS  "ISO  Basic  Synchronized  Subset" 

6.3  Message  handling 

*  Interim  Solution  :  Message  Header  derived  from  CCITT  X430 

*  MHS-MOTIS  "Message  Handling  System  -  Message  Oriented  Text  Interchange 

System"  (CCITT  X400  Serie) 

CEN/CENELEC  profile  A/3211  -  ISO/DIS  8505 

*  ODA-Kernel  "Office  Document  Architecture"  /ISO/DIS  8613 

-  PDA-3  "Document  Architecture  Level" 

*  Session  BAS  "ISO  Basic  Activity  Subset" 

*  TELETEX  includes  :  T61  (Presentation),  T62  (Session)  and  T70  (Transport) 

6. 4  Network  and  Communications 

*  ETHERNET  (CSMA-CD)  Carrier  Sense  :  multiple  access  -  collision  detection 

ISO/DIS  6802.3  "Local  Area  Network" 

*  HDLC  (LAPB )  High  Level  Data-Link  Control  /  ISO  7776 

*  ISO  Transport  class  0,2,4  :  I  SO/ 1 S  8072  -  ISO/ 1 S  8073 

Class  0  :  simple  class 

Class  2  :  multiplexing  class 

Class  4  :  error  detection  and  recovery  class 

*  LLC  "Logical  Link  Control"  /  ISO/DIS  8802.2  "Local  Area  Network* 

*  X21  bis  :  Use  on  PDN  of  DTE  which  is  designed  for  interfacing  to 

synchronous  CCITT  V-serie  modems,  Version  1984 

/6091 

CSO:  5500/A044  END 
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